System for retrieving data stored in a database

ABSTRACT

A computer-implemented, transaction-making, municipal bond trading system having a capability to conduct a private electronic auction of bid wanteds between a central brokers&#39; broker and multiple prospective remote bidders and to maintain a reference database of accurate individual bond lot descriptions and identifications, including CUSIP (trademark) numbers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/990,575 filed Nov. 17, 2004 now U.S. Pat. No. 7,310,051, which is acontinuation of U.S. patent application Ser. No. 09/321,638 filed May28, 1999, now U.S. Pat. No. 6,876,309, which is a continuation of U.S.patent application Ser. No. 08/943,995 filed Oct. 3, 1997, now U.S. Pat.No. 5,915,209, which was a continuation of U.S. patent application Ser.No. 08/342,809 filed Nov. 21, 1994, now abandoned. Any patent, patentapplication or other document referred to herein is incorporated byreference into this patent application as part of the presentdisclosure, but only for purposes of written description and enablement.

BACKGROUND

The present application relates the retrieval of data stored in adatabase or as computer files. More particularly, the presentapplication relates to methods and systems for searching or queryingsequentially data stored in at least one database.

Bonds are interest-bearing securities issued by governments, governmentagencies and quasi-government agencies (municipal bonds), or bycommercial corporations with the promise to repay the principal at afixed future maturity date. The present invention is applicable to thetrading of municipal bonds issued by state and local municipalities andwith corporate and other securities traded in a comparable manner aswill be apparent to those skilled in the art.

Securities brokers are licensed by the Securities and ExchangeCommission to buy and sell, or trade in financial securities includingcommercial stocks and bonds and municipal bonds, on behalf of members ofthe public, for a commission. Any licensed securities broker can tradein bonds, separate licensing is not necessary, but some brokersspecialize in particular types of bond. No formally organized exchangeexists for trading bonds. When a securities broker needs to find apurchaser for a municipal bond to complete a sale for a selling customeror needs inventory of municipal bonds from which to make a purchase fora buying customer, the securities broker will generally go to a broker'sbroker who typically specializes in municipal bonds and deals only withother brokers, not with members of the public. Brokers' brokers, hereinreferred to as “municipal bond brokers” or simply “brokers,” act onbehalf of broker dealers, herein referred to as “traders,” to maintain amarket on a riskless and undisclosed basis. Traders are individuals whomaintain and control a market within their firm for their sales people,but rely on brokers for transactions with the outside world, with whatis known as the “street” market. Brokers maintain “books” of the highestbid a prospective purchaser is willing to make, herein referred to as“bids,” and of the lowest “ask”, or lowest price asked by a prospectiveselling trader, herein referred to as an “offering”, on numerousdifferent municipal bond issues. An offering is a relatively passivelisting of an agency and lot as being available for sale at the askedprice. An offering lacks urgency and immediacy and lists of offering aremaintained as on-hand inventory by municipal bond brokers. When a clientwishes to make a quick sale of a bond lot that fact is broadcast toprospective buying traders as a “bid wanted” for a limited period oftime, typically a few hours, or a day or two at most, to solicit a highbid.

A trader, some firms have two or more traders, has the responsibility ofmaintaining inventory for a specific area of the municipal bond market,or type of bond, for example, insured bonds, short term maturity bonds,or long term maturity bonds. The bonds in inventory have a totalposition par amount known as the “position” of each lot and an offeringpar amount known as the “offer” or “offering” price. The position is anestablished price at which the bond lot was purchased and may beaveraged across different prices for groups of bonds in the lot, forexample, 10 bonds at 100, 20 bonds at 99 ½, and 30 bonds at 99 mightconstitute a lot of 60 bonds having a position price of 99.333, which isthe average cost of each bond in the lot. An offering quotes a price atwhich the lot, or a part of the lot, is for sale for example, “25 at 99¾”.

The function of a broker is that of both a buyer and a seller on everytransaction, analogously to a wholesaler. The broker buys from a sellingtrader and sells to a buying trader. The broker obtains a firm bidbefore making a purchase from a seller and is therefore not at risk. Theterms and parties to a municipal bond transaction are not publiclydisclosed although the new purchaser is registered as proprietor of thelot with the issuer, and receives interest payments, calls and othernotifications. The broker has no set “position” in the marketplace andis therefore able to be unbiased as to market direction.

Municipal bonds attract a wide following because of their tax-exemptstatus which also gives them a character of geographical interest. Allsuch bonds are federally tax exempt and they are generally tax exemptunder all superior jurisdictions. For example, New York City bonds areexempt from New York City, New York State and Federal income tax, butthe interest on such bonds is likely to be taxable; that is, subject tostate income taxes for out-of-state residents of, for example, NewJersey.

Because of the strictly geographical nature of the issuer, municipalbonds generally have a rather localized regional interest so that, forexample, residents of the state of Oregon may well be interested inCalifornia bonds but will have little if any interest in bonds issued inFlorida or New Jersey.

In the United States there are approximately one and one half millionissues of such tax-exempt securities but there is no exchange throughwhich they are traded and where a dynamic market can be made betweenwilling sellers and willing buyers in competition with one another todetermine a fair price for a given security having regard to allavailable information. Nor are there specialists for individual bonds ortypes of bonds as there are for commercial securities on stockexchanges. These commercial securities specialists are intimatelyfamiliar with the details of the securities in which they specialize andwith relevant market forces, and are therefore able to handle theirspecialist securities more efficiently than can other traders.

Instead of using an exchange and product specialists, most municipalbond transactions are channeled through a small number of municipalbroker's firms acting as brokers as described above. As of fall 1994,there are only twenty-one such firms in the U.S.A. One difficultyencountered by firms engaged in municipal bond sales is in obtainingaccurate and up-to-date information on any one of over a milliondifferent bonds.

Various electronic information means exist to assist municipal bondbrokers in trading municipal bonds. For example, some useful servicesare provided by brokers themselves whose function it is to match bidswith bid wanteds as quickly and as profitably as possible. Brokerscompete with one another to obtain bid wanteds from and to make dealswith their clients, municipal bond traders. To attract and retainclients and to encourage the continuous use of brokers' services, somebrokers make sophisticated information systems available to the traders.

A “Municipal Trading System” dated Aug. 19, 1993 from FABKOM, Inc.,discloses a computer-implemented municipal trading system for in houseuse by municipal bond broker's brokers which assists their internaltrading operations with outputs to proprietary information services suchas Telerate (The Blue List Ticker), Munifacts, and Reuters (trademarksof their respective owners). The FABKOM Municipal Trading System doesnot solve the problem of rapidly communicating bid wanteds to largenumbers of prospective bidders or to provide accurate up-to-date bondlot description information nor does FABKOM provide any new means forenhanced solicitation of bids from large numbers of potential buyers.

J. J. Kenny Drake provides a private, dedicated printer and optionally ascreen in a trader's office. Such additional hardware can beproblematical in the crowded office environment of many traders.

Another difficulty encountered by municipal bond brokerage firmsattempting to consummate a substantial volume of trades quickly is thatregulatory agencies prohibit brokers from making trades that areexclusively computer executed and require no physical intervention by abidder to authorize the bid. Further, the authorization has to berelated to an authenticated description of the security by a licensedprofessional. Unless there is voice-to-voice communication between buyerand seller, an exchange license is required.

Accordingly, there is a need for a system that can rapidly disseminateaccurate, up-to-date information on any one of more than a million bondlots, to hundreds of potential buyers and can quickly solicitprospective buyers for the lot, identify a high bidder and to effect aprofitable trade.

BRIEF SUMMARY OF THE INVENTION

The invention, as claimed, is intended to provide a remedy to thedifficulties encountered by municipal bond brokers in obtaining accurateand detailed information on municipal bond lots and sales while thetransactions are occurring. This problem is solved by providing acomputerized municipal bond trading system having the capability toconduct a private electronic auction of bid wanteds between a centralmarket-maker and multiple remote clients who are prospective bidders.

Preferably, bid wanteds included in the auction are renderedtime-sensitive by including a time limit for receipt of bids by themarket-maker. Transmission of bids to the market-maker from the biddersmust be confidential so that bids are not disclosed to other bidders. Inmaintaining bid confidentiality, the system thus operates in a mannerresembling a sealed bid auction such as is used for governmentcontracting, albeit with a much smaller time scale. Preferably, also,each lot on which a bid is wanted is electronically transmitted or madeavailable more or less simultaneously to all desired prospectivebidders, for example, by using a fax service to broadcast a bid wanted,stamped with an auction deadline to hundreds of traders to solicit bids.

By broadcasting a large number of traders in a short period of time andconstraining the solicitation of bid wanteds into the focused time frameof an auction, superior results can be obtained in that more tradersrespond more quickly and profitably, enabling the broker quickly toconsummate a satisfactory sale for a selling trader.

Preferably, the system includes a security master database of referencematerial, preferably refreshed nightly from a reference database, fromwhich the accuracy of broadcast bond lot descriptions andidentifications can be verified, corrected and supplemented, ifnecessary, enabling a broker to circulate bid wanteds with up-to-dateaccurate descriptions.

Communication with client traders may be made directly to a client'sworkstation over a WAN, using known linking means such as wired orwireless links via modems, network interface cards transceivers and thelike, or via facsimile, herein referred to as “fax,” by out-putting inhard copy at the client's premises or into a computerized fax receivingdevice.

Bids can be transmitted from clients to the market-maker in any suitablemanner. In a preferred embodiment they are transmitted by fax.

Direct electronic generation or input of bids by keyboard, mouse, stylusor other impersonal input device without employing a client's imprint ispossible, in accordance with the invention.

Also, simultaneous transmissions by competing clients across a networkcan be rendered highly secure using known coding, routing andverification means, if desired. However, some clients may believe, withor without justification, that network-transmitted bids can be illicitlyintercepted by competitors using computer-eavesdropping techniques suchas those employed by “hackers.”

BRIEF DESCRIPTION OF THE DRAWINGS

Some preferred embodiments of the invention, including the best modecontemplated of carrying out the invention, will now be described indetail herein below with reference to the accompanying drawings whichillustrate only one specific embodiment of the invention and in which:

FIG. 1 is a schematic block diagram showing the flow of data between abond selling trader and multiple buying traders linked via a municipalbond trading system according to the invention;

FIG. 1A is a schematic block flow diagram of a bond trade transactionperformed by the bond trading system illustrated in FIG. 1;

FIG. 2 is a schematic representation of a command menu screen for themunicipal bond trading system shown and described with reference to FIG.1;

FIG. 3 is a block diagram showing one possible process flow of a userinterface for the municipal bond trading described with reference toFIG. 1;

FIG. 4 shows a sample bond lot entry screen for posting bond lot data toa modified version of the trading system shown in FIGS. 1-3;

FIG. 5 shows a sample bid entry screen analogous to the bond lot dataentry screen of FIG. 4;

FIG. 6 shows a sample “Add CUSIP” (trademark) information screen forsupplementing, or correcting, bond lot information, for use in themodified municipal bond trading system referenced in relation to FIGS. 5and 6, with lot data entered;

FIG. 7 shows a portion of a sample offerings listing from a databaseresident at a broker's office;

FIG. 8 shows a portion of a sample offerings listing from a databaseresident at a trader or customer's office; and

FIG. 9 is a sample completed bid wanted form for use with, and at leastpartially generated by, the trading system of FIGS. 1-3.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to a computerized system providing newways of brokering municipal bonds, thus enabling municipal bond brokersto conduct business more efficiently and enabling a municipal bondbrokerage (or “broker” hereinbelow) to provide a more efficientmarketplace for bonds. It provides an in-house computer system employingnovel computer-implemented brokerage software. The system could beimplemented on a stand-alone or multi-user dumb terminal system, but ispreferably implemented on a local area network, herein referred to as a“LAN.” Enhanced embodiments of the system contemplate a wide areanetwork, herein referred to as a “WAN,” in which remotely situatedtrader customers can communicate across a digital network with a centralbrokerage house. An alternative embodiment of the invention is toregister the municipal bond trading system as a licensed exchange withthe Securities and Exchange Commission, hereinafter referred to as“SEC.”

Pursuant to the invention, the broker (broker's broker or municipal bondspecialist) compiles records of all offers received from various tradersand firms into a central listing of offerings. “Offerings” which havenot traded (because they did not receive their ask price) or low bidsmade against those offerings can be easily marked for inclusion in asilent auction pursuant to the invention as “bid wanteds”. Such a“silent” auction is a novel and beneficial feature of the invention, notheretofore known in the industry.

Traders participate in silent auctions, with secret bidding, and rely onbrokers to run these silent auctions. Referring to FIG. 1, in apreferred embodiment such as that shown in the drawings, the inventioncomprises a software-enabled, computer-implemented municipal bondtrading system 10 for use by SEC-registered municipal bond brokers firmsto serve the community of SEC-registered securities brokerage firms whodeal with the public, such as selling traders 14 and buying traders 12,for executing transactions in unlisted securities, especially municipalbonds, without disclosing the seller to the prospective buyer.

The municipal bond trading system 10 of the invention enables a brokerwho deploys it to perform a centralized market-making function in amanner providing many of the advantages of a live exchange such as theNew York Stock Exchange, without, in preferred embodiments, requiring anexchange license.

Although the municipal bond trading system 10 is shown in FIG. 1 asoccupying a central function between sellers such as selling trader 14and buying traders 12, it is to be understood that this is a schematicrepresentation, and as will be further explained hereinbelow, preferredembodiments of the municipal bond trading system 10 include componentsrunning at the premises of buying traders 12, and optionally, also atthe premises of selling traders 14 to integrate both sellers andprospective buyers into a coherent market-making system.

Unlike, for example, the J J Kenny-Drake McGraw Hill screen system,which places a dedicated printer or terminal in the office of a trader,the municipal bond trading system 10 of this invention can beimplemented in PC-compatible software running on a trader's existingcomputer hardware employing major operating systems such as DOS(available in several versions, for example, from Microsoft Corp, IBMCorporation, Novell, Inc.), Windows (trademark, Microsoft Corp.), AppleComputer Corp.'s operating systems, and possibly IBM Corporation's OS/2(trademark). This avoids interposing additional hardware into a trader'scrowded work area, and permits a user to multi-task the municipal bondtrading system 10 with other applications at the same workstation.

Preferably, the municipal bond trading system 10 uses operating systeminterrupts for the temporary insertion of time-sensitive screen messagesor overlays when the user has other applications on-screen.

A job lot 16 comprises a list of one or more bond lots, each of which isa bid wanted, offering or a dollar bond quote. “For sale” is an industryphrase which means that a seller has accepted a bid at a levelreasonably close to the lot's value and will execute on the bid.

A selling trader 14, who may be an owning institution or individual butis preferably an SEC-registered securities broker dealer, transmits oneor more job lots 16 of bonds for sale to the municipal bond tradingsystem 10 maintained by a broker, who functions as a “market-maker,” atany time convenient to the selling trader 14. Transmission of job lots16 to the municipal bond trading system 10 can be accomplished in anyconventional manner; written, faxed, telephoned, or the equivalent, butis preferably electronically effected in a file that can be directlyprocessed by the municipal bond trading system 10, for example, viaconfidential e-mail, as are communications from the market-maker to theseller, over data lines 15. Most preferably, the seller iscomputer-linked to the municipal bond trading system 10 on a LAN or aWAN.

Referring to FIG. 1A, after appropriate central processing employing themunicipal bond trading system 10, bid wanteds are circulated to buyingtraders 12, Step 202, in order to solicit bids 18. These functions aredescribed in greater detail herein below. Bids 18 are received by bondtrading system 10 from one or more buying traders 12 and transmitted tothe seller by any suitable means, such as fax or computer network, asdescribed above, for further processing, Step 206. If the selling trader14 accepts the bid 18, Step 208, the brokers' broker marks the lot “forsale,” Step 209, and completes the execution, Step 210, preferably withthe assistance of the municipal bond trading system 10, and thentransmits customary buy and sell tickets 20, Step 212, to the sellingtrader 14 for their internal processing.

As described above, in Step 214, if desired, offerings which have notbeen traded can be marked up and included in Step for circulation tobuyers as bid wanteds.

If traders are utilizing the system on their workstations, they willexecute a “buy” utilizing the program while the broker executes a“sell.”

In a modified embodiment, subject to compliance with licensingrequirements, the system can be operated as an exchange, providing adirect transaction between a selling trader 14 and a bidding trader 12,conducted through the intermediary of the trading system 10. The doublestep required in conducting a buy-sell transaction with both the sellingtrader 14 and the buying trader 12, can be eliminated. Alternatively,trading system 10 may receive bid wanteds in electronic form, withoutvocal communication, and system-select the best bid for entry andreferral to the selling trader 14 for acceptance, which electronicnon-vocal automated trading procedure currently requires an exchangelicense.

The system can be tailored to transmit information of the transaction tothe trader's in-house processing system for proper record keeping andaccounting and to maintain an inventory of bond lots in position for thetrader.

It is the broker's responsibility to attempt, in a timely manner, tofind a buyer for each lot in the job. Some institutions, for example,unit investment trusts, are required by regulation or their ownconstitutions, to have gone to every reasonable extent to have offeredbonds to numerous brokers before completing a sale to the highestbidder. The novel municipal bond trading system 10 of the inventiondescribed herein facilitates fulfillment of this requirement by enablingrapid distribution of job lots 16 to a wide base of customers, sellingtraders 12, and by providing quick and efficient means for evaluating,collating and transmitting even a large number of bids 18 to the sellerfor further action.

Before a trade is executed, a municipal bond lot must be identified witha Central Unified Security Identification Process number, hereinreferred to as “CUSIP (trademark)” issue identification number. CUSIP isa registered trademark of the American Bankers Association (“ABA”). Thebond lot must also have an authentic description and a par value,usually some thousands of dollars, describing the size of the lot.Unlisted bond descriptions are subject to change at any time. Forexample, bond ratings are continually changed by rating agencies, and abond may be called in for repayment on as little as thirty days' notice.Ratings and calls are an essential part of the description of a securityand can dramatically affect the character of the investment. It isaccordingly highly desirable to include such changes of description ineach bid wanted before distributing it, which presents a problem.

Failure to use a current and authentic description may require adisconcerting disclaimer to be included in the description, for example,“Not all calls may be listed.” Such disclaimers are very undesirablesales characteristics and create uncertainties regarding completion of atrade to a high bidder.

Authentic descriptions are available from a reference database, such asthe KENNYBASE (trademark) database maintained by Kenny InformationSystems, Inc., which is often identified by the shorthand term “KIS.”Reference herein to a “KIS database” or to “KIS” is to the KENNYBASE(trademark) database. However, the online access of such a referencedatabase during a transaction is impractical due to its slow downloadtime, the unwieldiness of the volume of data and the potential forincorrectly copied data.

To provide contemporaneous descriptions rapidly, in a manner suitablefor processing lots in volume, the invention employs a security masterdatabase 24, wherein bond descriptions are stored cumulatively, wheneverthe municipal bond trading system 10 encounters them, to be availablefor future use. The security master database 24 can be primed orsupplemented with preferred lists of bond descriptions and has noparticular limits, but it is much smaller than the reference database22, thus enabling a faster search and access capability. For municipalbond trading, the reference database 22 is preferably the KIS database.In a preferred embodiment, the structure of the security master database24 is substantially matched to the fields in the reference database 22and contains no additional fields, so that it may be purged of aged,inactive records without losing any historical transactional data orother useful data not available from the reference database 22.

The security master database 24 can be updated nightly from thereference database 22, to keep it within a day of the latestdevelopments. Alternatively, other means may be used to maintainsynchronicity of common data fields between the in-house security masterdatabase 24 and the remote reference database 22.

Each lot of a new job lot 16 is supplied with a description from thesecurity master database 24, which can be rapidly retrieved over a LAN,WAN or similar network. If no description is present on the securitymaster database 24, the description is pulled down directly from thereference database 22, which process is slower because of the relativedatabase sizes, the time taken to make a remote connection, and possiblequeuing delays if the reference database 22 server is busy.

Similarly, identification numbers such as CUSIP (trademark) numbers, ifnot supplied by the seller, are furnished or verified from the securitymaster database 24 based upon the seller's description, or, if notpresent on the house-controlled security master database 24, areobtained from the remote reference database 22 by searching on whateverdescriptive parameters are furnished by the selling trader 14. Thesefeatures of the municipal bond trading system 10 ensure that each bidwanted can be properly identified and authentically andcontemporaneously described for distribution to customers, buyingtraders 12, Step 201 (FIG. 1A), in a bid wanted form 26.

Once prepared, the bid wanted form 26 is distributed to the buyingtraders 12 to enable them to bid in a timely manner. Bids are firstsolicited, and if necessary, collected centrally, and then evaluated todetermine the high bidder, Step 205. Following this process, acompilation of bids is transmitted to the selling trader 14 for action.

According to the invention, these steps are accomplished in a silentauction, conducted electronically or on paper without the necessity ofvoiced person-to-person communication modes, such as telephone calls. Inthis silent auction, each bid wanted is provided with a bidding deadlineand is broadcast to reach multiple buying traders 12 prior to thatbidding deadline. Traders 12 wishing to bid on the lot offered arerequired to return a completed bid wanted form 28 to the centralmunicipal bond trading system 10 prior to the deadline if the bid is tobe considered. Bidding closes when the deadline passes. After acceptanceof a high bid by the selling trader 14 and the completion of any closingformalities, a bought-from ticket 34 is system-prepared and transmittedto the buyer for their records and processing, preferablyelectronically.

An optional but valuable feature of the silent municipal bond auctionaccording to this invention is the provision of timed alerts to warn ofthe approaching deadline. Preferably, bidding traders 12 are linked tothe municipal bond trading system 10 over a computer network so thatbidding deadline alerts can be overlaid, or otherwise displayed on abuying trader's screen at various times throughout the auction processto advise of the approaching commencement of an auction on a particularlot, to warn of expiration of the time limit, and to provide interimadvisories as the auction proceeds. Such alerts are preferably displayedon a system-wide basis on all selected and operational networked screensincluding those of brokers working with other applications on-screen atthe time. If desired, bidding trader modules 13 of the municipal bondtrading system 10 software can include switches or filters permittingthe user to choose which alerts should be flashed on-screen or whichshould be allowed to interrupt other applications.

Preferably, an on-screen bidding advisory message requires action by thebidding trader 12 to remove it, such as pressing a particular key, andthe advisory may include options, for example, “Display bid wantedform?”, if the form is not already on-screen.

Audible signals or messages may accompany or replace the displayedalerts. For example, distinctive musical chords may signify differentstages of the bidding process and voiced messages may be sent to tradershaving digital sound capabilities. Sound alone is probably notsatisfactory since an audible signal will not be received by traders whoare away from their screens. A small residual screen box, for example,can give a trader the opportunity to playback a missed audible messageto which they had failed to provide a requested response.

In a preferred display protocol, by way of example, an alerting messageis distributed fifteen minutes before the commencement of an auctionwhen bids are due. Then, fifteen minutes after an auction commences, ifno bids have been reported to the selling trader 14, a message such as“Bids Not Up!” can be distributed. Other similar messages can bedistributed at fifteen and five minutes prior to a deadline. Such alertscan be accompanied by full or abbreviated descriptions of the offeredlot for which a bid is wanted.

The invention also enables a seller to place a job on “Hold” by settingit up in advance for bid wanteds. Such preparation could take as long asone-half hour or more for large jobs. This advance preparation enablesthe seller to wait for favorable market conditions and quickly respondto changes in conditions with a timely transmission of bid wanteds tothe trading system 10.

The novel bond-lot auction procedure described herein provides aseparate, quick, economical and efficient auction for each bid wanted orjob lot offered. The process of disseminating bid wanteds and solicitingand collecting bids can be confined to a well-defined time frame. Theonscreen bid deadline alerts command a trader's attention, haveimmediacy and focus a trader's attention on the bid wanted particulars.The invention significantly improves the volume and quality of responsesreceived to a bid wanted and thence their profitability because traderscan enter bids with their own equipment: a concept which is unique inthe industry.

The municipal-bond marketing process is very competitive. Brokerscompete for the time and attention of buying traders 12 and compete toproduce results for the selling traders 14. The same trader may be aselling trader 14 on one trade and a bidding trader 12 on the next.Delays in distributing a bid wanted to a buying trader may lead tomissed opportunities for the seller if the trader buys a different lotwith comparable financials in the interim. Many selling traders 14 aresophisticated traders with ways and means of comparing the performanceof the specialist municipal bond brokers to whom they entrust their bondlots for marketing.

A market-making municipal bond broker's performance is greatly enhancedby employing the inventive municipal bond trading system 10, because thebroker can instantly transmit a complete and accurate bid wanted to alarge number of traders simultaneously.

Some advantages of using the municipal bond trading system 10 arereadily apparent in terms of more bids, shorter turnaround times betweena seller's listing of a job lot with a broker using the municipal bondtrading system 10 and receiving back an ordered list of bids received,fewer completion problems, and possibly better prices.

The problem of distributing bid wanteds to a specified number of buyingtraders 12 in a short time frame can be solved in various ways, but aparticularly preferred solution utilizes fax transmissions of bid wantedforms 26 to a specified group of buying traders 12 who can receive thebid wanted form 26 on paper, by computer or in both ways. This method oftransmission is also suitable for distributing bid wanted forms 26 toany individual buying trader 12. In preparing job lots 16 for faxbroadcasting, the municipal bond trading system 10 organizes all activejob lots 16 in a queue so that the broker can designate, or “tag,”selected lots for faxing. The system sorts tagged lots for faxing byauction time, and sends them to a fax service 30 at a predeterminedinterval before the auction commences.

Fax distribution of job lots 16 can be effected by transmitting bidwanted forms 26 to a fax service 30, which then transmits appropriatefax messages to the specified list of buying traders 12 across datalines 32. Of course, in the case of fax transmissions, data lines 32 aretelephone lines or telephone signal pathways. Most bid wanted forms 26will be transmitted to at least tens, and more probably, hundreds ofbuying traders 12. In 1994, one list of such prospective buyerscomprises nearly eight hundred names.

Preferably, to be functional in the municipal bond industry environment,a fax broadcast of bid wanteds should be completed within at least onehour and preferably in less time, for example, twenty or thirty minutesat the most in order to effectuate a timely auction and to becompetitive with traditional distribution methods. Such traditionalmethods include; individually calling and faxing bid wanted forms 26 topreferred customers; broadcasting printouts to dedicated printterminals; and, other, similar methods. Such time constraints for faxbroadcasting are presently prohibitive even for large offices withelectronic access to multiple fax lines, when due allowance is made forindividual connect and transmission times, data transfer rates overphone lines and for redialing busy numbers. The use of a commercial,external fax service, according to the invention, which employs one ormore fax servers driving banks of out-calling modems to make many faxcalls simultaneously, enables even small firms to compete moreeffectively by fax broadcasting. For example, MCI Communications, Inc.provides a fax service which is believed to have access to as many asfour or five thousand modems and associated telecommunications networkfacilities. Such services can transmit large numbers of faxes more orless simultaneously and can, for example, meet a target for faxtransmission of a one page message to five hundred traders within halfan hour.

The fax broadcast method of bid wanted distribution described herein hasmultiple advantages of particular value to the sponsoring market-maker.No special equipment is required in the customer's office; every traderand broker has fax facilities. Faxed bid wanteds can be processed inhard copy or electronically, at the customer's discretion, faxbroadcasting is the fastest available means of broadcasting bid wantedsto traders without making prior arrangements. And, most importantly, afaxed bid wanted form 26 with blank bid entry areas provides an idealvehicle for returning completed bids, also by fax. Use of faxbroadcasting greatly enhances the efficiency and commercial viability ofthe bid wanted auction system of the invention.

Preferably, and in addition to receiving faxed bid wanteds, a number ofregular clients are computer networked with the municipal bond trading,system 10 to receive bid wanted forms 26 in compatiblecomputer-processable format. If the network is used for returning acompleted bid wanted form 28 to the central market-maker, it ispreferred that a manual signature be entered on the completed bid wantedform 28 to authorize the bid.

Preferably, the bid wanted form 26 contains the full particulars of eachbid wanted lot, including its CUSIP (trademark) number and description,state of origin, maturity, par amount, and coupon values (yield andconcession particulars, net yields, and dollar, gross and net dollarprice) if appropriate. For use in a fax-broadcast marketing system, theform preferably also includes blanks completable by a bidding traderwith bid particulars, yield, dollar or other amount, as appropriate, andbidder identifiers, including the name of the bidding trader. Yields andother calculable numericals can of course be system-calculated andautomatically posted from base data. A buying trader 12 can quicklywrite minimal bid information on a hard copy of such a bid wanted form26, sign it, and fax it back to the market-maker, who receives a signedbid with full and accurate lot particulars complying with regulatoryrequirements and which does not need to be checked, verified orcompleted. Conventionally received bids are often incomplete, orinaccurate, and require confirmation.

The command menu screen shown in FIG. 2 comprises a conventional ribbonbar 40 across the top (or, if desired, the bottom) of a user's screen42, from which drop-down menus can be activated, as shown. In general,the menu descriptions are customary ones for a database application;edit menu 46, record menu 48, utility menu 50, and window menu 52 alllist conventional functions which are known to anyone familiar withdatabase management programs. File menu 54, history menu 56, and archiveselection menu 58 list choices of files and functions that are specificto the municipal bond trading system 10 of the invention. The bidwanteds selection highlighted on the file menu 54 initiates a procedurethat associates lot records with their bidding status. Utility menu 50utilizes an overlaid archive sub-menu 58 to present one or more archivefunctions. Referring to archive submenu 58, transaction activity isclassified for storage in several different ways, as shown by the menuof selections such as “Lots & Bids” and so on. Archive functions permithistorical records to be copied to tape, or other remote or backuppermanent storage, enabling system storage capacity to be maintained bypurging old records. Provision is made for storage (typically to harddisk) and archival of the host bond broker's daily system-generatedtransactions by selection of the Lots & Bids option, or to update thebrokerage firm's home office records or the security master database 24records, and to store a record of all outgoing faxes and E-mail usingthe “outgoing EB” function of archive submenu 58, which refers tooutgoing e-mail broadcasts. The e-mail legend in e-mail window 44describes a capability to send bid wanted forms 26 by e-mail, inautomated mode to a predetermined destination list, which may beselected from multiple lists of buying traders 12, grouped according totheir buying preferences, and networked with the municipal bond tradingsystem 10. The remaining functions shown in FIG. 2 are standard orself-explanatory and will not be further described.

As indicated in menu box 44, the preferred embodiment shown employs anauto-open feature so that a time-sensitive bid wanted form sent viae-mail using this menu selection is promptly displayed on a buyingtrader's 12 screen, interrupting other applications if necessary.

Exemplary database structures for exemplary databases usable inpracticing the invention including structures for the files listed infile menu 54 are set forth in the Database Table at the end of thisspecification.

Menu bar 40 can be present on some or all screens of the municipal bondtrading system 10 software to provide users with a wide range of viewingand administrative functionality at any time. Following traditionaldatabase management practice, not all functions may be available fromall software screens and available capabilities may be adjustedaccording to a user's status so that, for example, only an administratorcan access utility menu 50.

Referring to FIG. 3, multiple options are displayed when the municipalbond trading system 10 is opened, enabling a brokers' broker to conductnormal day-to-day municipal bond trading functions with the advantagesdescribed herein. The “ORDER” through “SELECT” functions across the topof FIG. 3 can be presented as a menu or a button bar of user selectionsor in any other convenient way. Each selection provides an input windowor screen as will now be described.

The Order button 60 sets the order in which lots are viewed. Lot data iseither electronically transmitted from a seller 14 or can be manuallyentered in a program button (not shown) or elsewhere. The New Job button62 provides for job creation, lot data entry and verification, andpermits selected actions to be taken on a newly created job. The On-Holdbutton 64 permits jobs to be put on hold during the new job entryprocedure, and later returned to active status. The Lot Action button 66opens a new Lot Action Button Bar 68, or menu, which enables a user toperform multiple actions on a lot. The Bid Entry button 70 provides forentry of bid details received from a buying trader 12 and for action ona bid.

With Lot Action Button Bar 68 open, the user's system can be said to bein a bid/offer state from which a desired trade sequence may beselected.

Duplicate Bid Action button 72 provides options in case multiple bidsfor the same lot are received from the same buying trader 12. The Findbutton 74 enables a trader to search all available lots in the databaseon a variety of user-selected criteria for example, yield, maturity,issuer, geography and the like. The Print/Fax button 76 permits selectedlots information to be output from the system and can include formats,filters, styles and addresses to facilitate output, especially toprovide a quick response to a buying trader 12. The Select button 78enables a trader to create one or more private filters for use with theFind button 74 or the Print/Fax button 76.

Activating the New Job button 62 opens window 80, which enables a sellerto post job data such as customer information identifying and describingthe selling organization, as desired, trader information identifying theindividual selling trader, the number of lots in the job, and timequalifiers for entry of the new job into a bid wanted auction. Tofacilitate data-entry, this information can be system-provided byselection from lists or by using defaults.

Window 82 provides for the entry of lot data including an identificationnumber, notably, for municipal bonds, a CUSIP (trademark) number, and apar amount for each lot, representing the value of the lot at par,typically, for example, on the order of five or ten thousand dollars.

Window 84 permits the user to verify, complete, and update the lot dataas necessary, and, if necessary, interrogates the remote referencedatabase 22, in this case, the KIS server, for completion orauthentication of data. Employing an issue-identifying CUSIP (trademark)number, the user or system checks the house-maintained security masterdatabase 24 and retrieves a full, authenticated issue description asdown-loaded (or updated or checked) the previous night from thereference database 22, the KIS server, and incorporates this descriptioninto the new job for itemizing in a bid wanted. Description retrievalcan be effected with the usual speed of direct client access to alocally networked file server. If the CUSIP (trademark) description isfound in the security master database 24, processing proceeds to the jobcomplete window 86.

If the CUSIP (trademark) number is not in the security master database24, an inquiry is placed in a lookup queue of the reference database 22,branch 88, to obtain an identification number using available bond issuedescription, and the full, up-to-date particulars including calls andratings are received, logic block 90, returning to the job completewindow 86.

A complete job can be acted on by the user in a number of ways,depending upon the nature of the job, as shown in the bottom row ofbuttons 92-98 in FIG. 3. If the job is a bid wanted, an auction iscreated specifically for that job, using the Bid Wanted button 92. Ifthe job is a completed offering, dollar bond or auctionable bid wanted,ready for distribution, it can be dispatched for broadcast via the Sendbutton 94 to the fax server, or to proprietary information services, forexample, Kenny S&P's Blue List Bond Ticker, currently broadcast overTelerate, Reuters, and Bloomberg Information Services. Activating theOff-the-wire button 96 ensures that the relevant job lot 16 is notbroadcast. Activating the Hold button 98 puts the job on hold forchanges to be made or information to be added.

Bid wanteds broadcast to outside information services such as KennyS&P's Blue List Bond Ticker can be indexed chronologically for deliveryto customers or prospects with the latest lots listed first. Offeringsand dollar bonds, which may not be time-sensitive, can be listed in anydesired order.

Referring to the Lot-action-button Bar 68, the Bid-entry button 100accesses the bid entry screen of FIG. 5. The bid entry screen isaccessible from both button bars because some users will not have accessto the lot action bar, such as administrative assistants clerks, and thelike. The Bid-up button 102 marks the record of a job lot 16 as bid upto the seller meaning that one or more bids have been received and sentto seller 14 whose action is awaited. The “Will Not Trade” (“WNT”)button 104 marks the record as “Will Not Trade” when the seller hasdecided not to sell because bids received are too low, or for any otherreason. Options marking the record as priced, that is, offered, or notpriced, or traded away, if the lot has been sold through other channels,can be added if desired.

For Sale button 106 marks the job lot record accordingly whenever a bidis accepted and execution will take place. Sell button 108 executes atrade, marks a record as sold to the buying trader 12, and initiatesroutines to make a bought-from ticket 33 for faxing to the buying trader12 for their internal processing; to report the transaction totransaction files, for example, in a nightly recap of activity; todisplay “SELL” and to cancel a “SELL” instruction; and, finally, theupdated record can be copied to a new offerings file, with a query as tothe price, to be re-offered.

Button 110 is a cancel-sell button enabling a trade to be canceled orbought back from a buying trader 12.

Buy button 112 marks a job lot record as bought; makes buy and selltickets for fax to the seller for sending to their back office.Transaction records are updated. The Cancel-buy button 114 enables a buyto be canceled. All buys and sells file records can be exported to thebroker's back office for processing and delivery of records.

Re-offer button 116 enables recently sold lots to automatically postedas a duplicate offering item with a reoffering price. History button 118displays a history of items or lots by any desired parameters, forexample, by CUSIP (trademark) number and trade date. Calc button 120provides a calculator for trial calculations on a bond lot. Fax Sellerbutton 122 sends a fax of auction results to seller 14 and Menu button124 returns to command menu 40.

The bidding status of a bond lot record is equivalent to its tradingstate. Thus, selection of one of the buttons shown in FIG. 3, such asBid Entry 100, Bid Up 102, Sell 108, Buy 114, Reoffer 116, on Lot ActionButton Bar 68, puts the system in a state specific to that tradingactivity, as described hereinabove, i.e. a trade-specific state, ortrading state, enabling the user to select a desired trading state froma plurality of available trade specific states.

The screens of FIGS. 4-6 show possible embodiments of user interfacesfor a slightly modified version of trading system 10. In common withother developmental technical projects, software undergoes variouschanges and revisions as it evolves from concept to realization. Thus,the screens of FIGS. 4-6 exhibit minor variations from the system asdescribed with reference to FIGS. 2 and 3. Other possible variationswill be apparent to those skilled in the art.

The lot entry screen of FIG. 4 can be considered as a modified form ofwindow 80 called down by new job button 62 (FIG. 3). The screen shownhas a system header 130 identifying the system loaded, the versionnumber, today's date and a settlement date. Directly beneath systemheader 130 is a menu bar 132 which differs slightly from ribbon bar 40of FIG. 2 in that E-mail is not directly available from this screen anda database selection menu is added to permit the use to access varioussystem databases, such as traders, offerings, and so on. With the lotentry screen displayed, only edit, window and help functions areavailable, these menus are not available.

In the FIG. 4 lot entry screen, the broker can select a trader 134 andbrokerage firm 136, referenced on the screen as a “satellite”, bysetting the respective radio button indicated generally at 138 to sortthe selected list. The broker can also select both a selling trader toreceive the order and the lot type desired, that is, either a bidwanted, an offering or a dollar bond, via lot-type button 140. The “Notin Comp/In Comp” option 142 allows the broker to notify the trader ofthe lot to make a higher, that is, more competitive, bid in order totrade or execute the bond lot. “In Comp” means the bid is in competitionwith a prior bid that the seller of the lot already has. The default forthis function is set to “Not in Comp”. The individual broker responsiblefor the lot is identified by name via Choose Broker window 144.

Bid wanteds received back from bidding traders 12 by fax or other meansare posted to the trading system 10 using a screen such as that shown inFIG. 5. A new record is created in a bids database which is relationalto a lots database, keying on a unique record number (not shown).Referring to FIG. 5, a new bid by bidding trader 12, in this case JeffClark, from a hypothetical brokerage firm 136, 1st Albany Corp, is beingentered on a lot identified in lot selection box 146 by the hostbrokerage (broker's broker) as lot “A-1-VA”. Jeff Clark is bidding ayield 148 of 4.500 and a concession 150 of 5.000, that is, ½ point, onthe lot. If desired, the concession can be selected in concession box152. The buttons to the left of the trader and brokerage list windowprovides helpful data entry functions, as indicated by their labels,which are self-explanatory.

Re-enter button 154 recalls the latest record for changes. Other bottomrow buttons 154 save the newly created bid to an internal databaserecord unless a cancel option is selected after “quit”. The Will Bid andPass buttons 154 tag the record accordingly with its current status. Anupper row of buttons 156 permits existing bid records to be reviewed oracted upon, as indicated by the button labels, are alsoself-explanatory. Data changes in the will bid/pass records willautomatically generate and transmit messages to the traders to thateffect reminding them to take appropriate action within the relevanttime limit. The lot CUSIP (trademark) number and description appearalong the bottom of the screen.

The Add CUSIP (trademark) screen of FIG. 6 can be called up from anydesired point in the system when it is desired to consult originalreference database records, remotely, or locally, for example from lotdata entry window 82 shown in the flowchart in FIG. 3. This screenallows the broker, or broker's clerk, to locate and add a CUSIP(trademark) number and the par amount to incomplete lot informationprovided that the lot description is adequate to be uniquely matched.The check lot data 84 function shown in FIG. 3 also calls this screen toallow modifications to the data.

Referring to the Add CUSIP (trademark) screen shown in FIG. 6, buttonswith labels similar to buttons or menu selections described withreference to FIGS. 2 or 3 provide the functions described thereat. Thelower half of the screen displays lot information withdrawn from thelocal or remote reference database. Other functions will beself-explanatory from the button labels. The magnifying-glass iconbutton 158 initiates a search of the local security master database 24for records matching the loaded lot. If none is found, remote referencedatabase 22 can be consulted by activating Scan KIS button 160, whichmay take time. Other functions include a Controlling Bkrs button 162enabling a controlling broker to be designated or changed. A controllingbroker organizes the bidders on the lot and ensures that past biddershave been contacted and advised of time limits for the bids. The programautomatically selects the controlling broker based on the geographicallocation of the lot. Group option 164 enables a broker to reset a groupcode based on the geographical location of the lot. Job Entry button 166enables the broker to modify the order in which lots from a job aredisplayed, by modifying the order of column headers in the listing. Holdjob button 170 allows the broker to choose to put a hold on the currentjob until more suitable market conditions arise, or other delayingfactors subside. This option also allows the broker to cancel a hold andresume active status on the job.

FIG. 7 shows a sample system menu selection bar and a partial listingfrom an offerings database (sorted on maturity date) resident at thebroker's office. The details of the listing will be apparent to thoseskilled in the art, having regard to the foregoing description, but ofinterest are the records for trader ABC, here marked as “ABC-NY” shownintermingled with records of other traders. The listing is sorted bymaturity date.

FIG. 8 shows a similar partial listing of the inventory of ABC includinga different branch office, which could be resident at the office of ABC.

Referring to FIG. 9, the bid wanted form 26 shown therein is suitablefor rendering on standard paper, for example letter size, which can listof the order of seven bond lots for bid, of which two are shown. Form 26comprises a source broker identifying header 172 under which anaccreditation 174 of the bond description source (CUSIP) appears alongwith a disclaimer. Across the top of the form is an electronicallyposted fax address 176 of the bidding trader 12 to which the bid wantedform 26 is sent. This is useful as it identifies the bidder when thecompleted bid wanted form 26 is faxed back to the broker. The broker'slot identification number 178 appears to the left of a lot description180 which is accompanied by complete lot information including CUSIP(trademark) number 182, rating 184, rating agency 186, call information188, coupon 190 and maturity 192. As completed, a manual bid 194 hasbeen entered in the space provided and the bid is authorized by thetrader's signature 196.

Optionally, the municipal bond trading system of this invention caninclude, or be embodied in, a remote trader module, and allow buying orselling traders to maintain their own inventory records on theirpersonal computers with bond lot information segregated between publicand private information. The system maintains local area networkinventory records for the trader, while reporting “offers”, via modem,to the broker's records, such as those shown in FIG. 8.

The public information to be included in a “street” or publicizedoffering can comprise the par amount, description and an asking priceexpressed as a yield, concession or dollar price.

In addition to the public information, a bond lot can be supplied withprivate information, using the trader module, which private informationcomprises items such as total position size or par amount, dollars atrisk, a hedge price (a price at which to sell futures against the bondlot, an average cost, a profit or loss at the asking price and a salescredit (or commission, for in-house sales staff).

Preferably, the trader is networked with the trading system 10 so thatthe municipal bond trading system offering database is automaticallyupdated with the public information on a bond lot as this information isposted or updated at the trader's personal computer. The bond lotdescription and CUSIP (trademark) number can be verified either fromsecurity master database 24 or reference database 22, at the broker'sfacility by the trading system 10, as described herein, and relevantadditions or corrections can preferably also be transmitted to theremote trader.

This process of maintaining duplicate records on the trader's hardware,makes tagging an offering and requesting a bid wanted auction a muchquicker process, which is another unique and beneficial feature of theinvention.

Furthermore, verification of bond lot descriptions against KIS sourcedata by the central trading system 10 enables a trader to work withaccurate, verified descriptions, without having to make their own KISserver access arrangements which would be slow and costly for a traderat a facility lacking a security master database which is refreshednightly.

The inventive municipal bond trading system 10 described herein providesa novel bond lot auction process and a novel bid wanted fax broadcastingprocess enabling buying traders to be brought together with sellers totrade bond lots in new and valuable ways. Authenticated bid wanteds canbe rapidly broadcast to any number of buyers using the fax broadcastingsystem, according to a timetable specific to each bond lot. The auctionprocess commands attention with its timetable and onscreen alerts andcontains the solicitation of bid wanteds in a desired time frame and atthe same time enabling any buying trader easily to bid on a lot. Moretraders are reached more effectively, leading to more and higher bidsand quicker sales at better prices for sellers. In addition, fullhistory information is readily available to facilitate future marketingand sales strategies, and in particular, individual traders can betracked, and their buying or selling histories can be maintainedindependently of the brokerage firms with which they are associated, sothat they can be more effectively serviced when they change firms.Furthermore, by providing a software means to deliver printed bid wantedforms to buying traders, any need for dedicated hardware can be avoided.

It will be understood that the systems and software referenced hereininclude, either explicitly or implicitly, software implemented oncomputers or other appropriate hardware, including such otherintelligent data processing devices having a processor, data storagemeans and the ability to support an operating system, with or withoutuser interfaces, for example, file servers, as may be useful inachieving the objectives of this invention.

Software components and applications embodying the invention can bedistributed in electronic bit storage on magnetic, optical, bubble orother media, and optionally in transportable form to be interactive withan electronic reading device, for example, on computer or opticaldiskettes, or may be distributed over wired or wireless networks forstorage by the recipient on such media.

Preferred embodiments of the invention provide such media-storedsoftware in a commercial package accompanied by instructions in printedbook or booklet form, for deployment of the software on particularembodiments of a general purpose computer to cause same to operate as aspecial purpose computer, in accordance with the objectives of theinvention. License agreements and registration as a means for updatingmay also be included. Alternatively, the instructions may also beprovided as data files.

It will further be appreciated that such media-stored softwareconstitutes an electronic customizing machine which can interact with amagnetically or optically cooperative computer-based input deviceenabling the computer to be customized as a special purpose computer,according to the contents of the software. To cause a computer tooperate in such customized, special-purpose mode, the software of theinvention can be installed by a user or some other person, and willusually interact efficiently with the device on which it is resident toprovide the desired special-purpose qualities, but only after theselection of a certain set of configuration parameters. When soconfigured, the special-purpose computer device has an enhanced value,especially to the professional users for whom it is intended.

Also, different fields are maintained for each bond parameter providingthe broker, and if so linked, the trader, with the ability to sort bondlots by any such desired parameter.

While some illustrative embodiments of the invention have been describedabove, it is, of course, understood that various modifications will beapparent to those of ordinary skill in the art. Such modifications arewithin the spirit and scope of the invention, which is limited anddefined only by the appended claims.

Database Table

Sample Database Structures Usable in the Municipal Bond Trading SystemDescribed Herein

1. Lots

1 CUS_CHG C 1 2 JOBENTRY N 5 3 ITEMNO N 4 4 TIMELIMIT C 40 5 CUSIP C 9 6PARAMT N 6 7 GROUP C 2 8 STATE C 2 9 STATUS C 15 10 ITEMSTAT C 4 11COUPON N 7 12 MATURITY D 8 13 DESC C 40 Total 1442. Bids

25 Yield N* 5 26 Concession N* 6  26a Concession Plus N* 6 27 Dollar N*8 28 Gross Dollar Price N* 9 29 Net Dollar Price N* 9 30 Net Yield N* 531 Net Yld To Call N* 5 32 Net Yld To Par Option N* 5 33 Net Yld ToSink'g Fund N* 5 34 Specification C 15 36 Cover N* 6 37 #Posit's OfBidder N* 2 38 Out By N* 6 51 Bidder C 10 52 Trader At Bidder C 20 53Posted C 6 54 Inputter C 6 N* = calculated3. Customer Master

1 Customer Code C 11 2 Security Dealer C 30 3 Addr1 C 30 4 Addr2 C 30 5City C 30 6 State C 2 7 Zip C 10 8 Exchange Assoc. C 12 9 Clear throughC 25 10 DTC C 4 11 NSCC C 4 12 Tax I.D. C 10 13 Tel C 14 14 Fax C 144. Trader Master

1 Trader Code C 6 2 First C 15 3 Last C 15 4 Title C 12 5 Sal C 12 6Telno1 C 18 7 Telno2 C 18 S Faxno1 C 18 9 Faxno2 C 18 10 Dept. C 12 11Interests C 30 12 History C 20 13 Memo M5. Firm Master

1 Customer code C 11 2 Firm C 30 3 Addr1 C 30 4 Addr2 C 30 5 City C 30 6State C 2 7 Zip C 10 8 Exchange Assoc. C 12 9 Clear through C 25 10 DTCC 4 11 NSCC C 4 12 Tax I.D. C 10 13 Main Tel C 14 14 Main Fax C 14 15P&S Name C 30 16 P&S Tel C 14 17 P&S Fax C 14 15 P&S Name C 30 16 P&STel C 14 17 P&S Fax C 14 18 Buy Contracts Name C 30 19 Buy Contracts TelC 14

What is claimed is:
 1. A system for trading bonds electronically, thesystem comprising at least one processor and at least one tangiblememory device having software stored thereon, the at least one processorconnected over a computer network to at least one selling user computerand a plurality of bidding user computers, and wherein the software,when executed by the at least one processor, directs the at least oneprocessor to: transmit a list of bonds to a selling user computer;receive from the selling user a selection of a bond from the list ofbonds to be included in a bid wanted; receive a bid wanted for at leastone bond lot comprising the selected bond from the selling usercomputer; transmit the bid wanted to a plurality of bidding users;receive a plurality of bids responding to the bid wanted from theplurality of bidding users; and transmit to the selling user computer alist of the bids received from the plurality of bidding users.
 2. Thesystem of claim 1, wherein the list of bonds transmitted to the sellinguser is sorted by maturity date.
 3. The system of claim 1, wherein thesoftware, when executed by the at least one processor, further directsthe at least one processor to transmit to the selling user coupon datafor each of the plurality of bonds on the list.
 4. The system of claim1, wherein the software, when executed by the at least one processor,further directs the at least one processor to transmit to the sellinguser maturity data for each of the plurality of bonds on the list. 5.The system of claim 1, wherein the software, when executed by the atleast one processor, further directs the at least one processor totransmit to the selling user issuer data for each of the plurality ofbonds on the list.
 6. The system of claim 1, wherein the software, whenexecuted by the at least one processor, further directs the at least oneprocessor to transmit to the selling user yield data for each of theplurality of bonds on the list.
 7. The system of claim 1, wherein thesoftware, when executed by the at least one processor, further directsthe at least one processor to transmit to the selling user market datafor each of the plurality of bonds on the list.
 8. The system of claim1, wherein at least one of the bonds on the list represents a bond orderthat has not traded.
 9. The system of claim 1, wherein at least one ofthe plurality of bonds represents a bond offering.
 10. The system ofclaim 1, wherein the software, when executed by the at least oneprocessor, further directs the at least one processor to receive a queryfrom the selling user for a bond list, the list of bonds comprising aplurality of bond offerings retrieved in response to the query.
 11. Thesystem of claim 1, wherein the list of bids is sorted by at least one ofyield and price.
 12. The system of claim 1, wherein the software, whenexecuted by the at least one processor, further directs the at least oneprocessor to identify a high bid from the plurality of bids, the list ofbids comprising the high bid.
 13. The system of claim 1, wherein the bidwanted comprises at least one of a description, a maturity date, a parvalue, a coupon value, a yield, and a settlement date.
 14. The system ofclaim 13, wherein the at least one of the description, the maturitydate, the par value, the coupon value, the yield, and the settlementdate is system-incorporated into the bid wanted.
 15. The system of claim1, wherein the bid wanted is transmitted to a plurality of specifiedbidding users selected from a list of bidding users.
 16. The system ofclaim 1, wherein the bid wanted is transmitted to a plurality ofspecified bidding users selected from a predetermined destination listof brokerage firms.
 17. The system of claim 1, wherein each of theplurality of bids are not disclosed to other bidding users.
 18. Thesystem of claim 1, wherein the software, when executed by the at leastone processor, further directs the at least one processor to receive abond description from the selling user and system-incorporate into thebid wanted a unique issue identifier associated with the bonddescription.
 19. The system of claim 18, the bond description receivedwith the selling user selecting a bond from the list of bonds.
 20. Thesystem of claim 1, wherein the selling user is able to accept at leastone of the bids transmitted to the selling user, and wherein thesoftware, when executed by the at least one processor, further directsthe at least one processor to receive an acceptance of at least one ofthe bids, and execute a trade of the at least one bond lot between theselling user and at least one of the plurality of bidding user thatsubmitted the accepted at least one bids.
 21. A system for trading bondselectronically, the system comprising at least one processor and atleast one tangible memory device having software stored thereon, the atleast one processor connected over a computer network to at least oneselling user computer and a plurality of bidding user computers, andwherein the software, when executed by the at least one processordirects the at least one processor to: transmit a list of bonds to aselling user computer; transmit to the selling user at least one item ofbond data for each of the plurality of bonds on the list, the at leastone item of bond data comprising at least one of coupon data, maturitydata, yield data, and issuer data; receive from the selling user aselection of a bond from the list of bonds to be included in a bidwanted; receive a bid wanted for at least one bond lot comprising theselected bond from the selling user computer, the bid wanted comprisinga unique issue identifier system incorporated into the bid wanted;transmit the bid wanted to a plurality of bidding users; receive aplurality of bids responding to the bid wanted from the plurality ofbidding users; and transmit to the selling user computer a list of thebids received from the plurality of bidding users.